1. Field of the Invention
The present invention relates generally to techniques for integrating different telecommunication systems and services. More particularly, the present invention relates to a standard interface which permits telecommunication services created in one Service Creation Environment (SCE) to be used in a number of different Execution Environments (EEs).
2. Description of Prior Art
Telecommunication services may be provided by executing machine-level code in telecommunication hardware such as telephone network switches and computers. The telecommunication hardware which executes the machine-level code may be more generally referred to as an Execution Environment (EE). The EEs may serve to, for example, route data packets in a data communication network or direct calls in a telephone network switching system. A group of EEs can provide interactive services to network users, and transmit data, documents and video through the network. Exemplary EEs include Service Switching Processors (SSPs), Service Nodes (SNs), Intelligent Peripherals (IPs) and Service Control Points (SCPs), all of which may be elements of an Intelligent Network (IN) architecture. Further detail regarding INs can be found in, for example, O. Mizuno et al., "Service Specification Description and Service Logic Program Generation for Intelligent Networks", Proc. of the International Council for Computer Communication Intelligent Networks Conference, May 4-6, 1992, pp. 430-440, which is incorporated by reference herein.
Under current practice, the telecommunication services provided in each EE are typically programmed using a specific development tool in a high-level programming environment. The high-level programming environment may be more generally referred to as a Service Creation Environment (SCE). Exemplary development tools include decision graph editors, spreadsheets, computer-aided systems engineering (CASE) tools, and Finite State Machine (FSM) editors. One exemplary type of FSM editor uses the standard CCITT Service specification Description Language (SDL), which represents telecommunications services in a graphical format to facilitate service development. The service to be provided in each EE is generally developed using a dedicated SCE, which runs on a computer workstation and provides a set of service development tools based upon a particular user paradigm. The SCE typically produces a service description file in a proprietary format developed by the SCE vendor. The proprietary service description file is then translated into a lower-level code suitable for directing an EE to provide the desired service, and therefore can usually only be used with a corresponding EE from the same or a related vendor.
The close coupling between SCEs and EEs under current practice presents a number of problems. One problem is that network services developed in one SCE can typically be used only in a corresponding EE and cannot be reused in different EEs. Another related problem is that the SCEs and EEs of one vendor generally cannot be interfaced to those of other vendors. In order to provide an interface between currently existing network services and a number of different EEs, it may therefore be necessary to redesign existing services to incorporate the interface. As a result of these problems, network providers, such as Local Exchange Carriers (LECs), long-distance carriers and foreign Postal, Telephone and Telegraph companies (PTTs), may have difficulty supplying telecommunication services in a timely and reliable manner. These problems are described in, for example, D. Singh and D. Garrison, "Requirements for Service Creation Platforms in an Open Systems Environment", Proc. of the International Council for Computer Communication Intelligent Networks Conference, May 4-6, 1992, pp. 162-174, which is incorporated by reference herein.
Several different approaches to the SCE-EE interface problem have been identified. One possible approach involves using a universal application-oriented language (UAOL) to program services in all SCEs. A related approach could involve using a standardized service execution processor (SEP). An exemplary standard SEP is disclosed in S. Esaki et al., "Service Logic Execution of IN Multi-vendor Environment--Introduction of SLP Execution Processor", Proc. of the International Council for Computer Communication Intelligent Networks Conference, May 4-6, 1992, pp. 441-450, which is incorporated by reference herein. Although either of these approaches may have been feasible if the telecommunication industry had initially settled upon a standard UAOL or SEP, no such standards are currently in widespread use. In addition, a UAOL capable of accommodating multiple service applications will generally be a complex high-level language, and will therefore not be easy to use. Implementing either the UAOL or standard SEP approaches at the present time would probably require redesign of existing network services programmed using non-standard languages or processors.
An alternative interface may translate object code between different SCEs and EEs. Object code translation typically involves translating source object code into a generalized assembly language, and then generating target object code from the assembly language. Object code translation has the advantages of being generally transparent to service users and an efficient means for generating the lower-level code required in a particular EE. However, this approach is inflexible to changes in service applications, and may not be well suited to programs which utilize run-time interpretation.
A technique presently used in prior art telecommunication system interfaces is cross-compilation. In general, cross-compilation involves designing a different compiler for translating code between each SCE and each EE. By using separate compilers for each interface, the services developed in any SCE may be used on any other EE, and therefore many of the above-noted problems are avoided. However, this approach may be prohibitively expensive in applications which include a large number of SCEs and EEs. The compiler development cost is generally a quadratic function of the number of SCEs and EEs. For example, if a telecommunication system includes m SCEs and n EEs, the cross-compilation approach will generally require the development and support of m.times.n compilers. An interface technique currently used in the context of higher-level programming languages is based on a common intermediate language. This approach was used in 1961 to develop a Universal Computer Oriented Language (UNCOL). See T. Steel, "A First Version of UNCOL", Proc. Western Joint Comp. Conf., pp. 371-377, 1961. Common intermediate languages typically include n front ends, each translating high-level code in one programming language to the intermediate language, and m back ends, each translating programs in the common intermediate language to a specific machine-level language, or target code. As a result, only n+m compilers must be written to interface each of the n SCEs to each of the m EEs, as opposed to n.times.m compilers in the cross-compilation approach. See, for example, A. Tanenbaum et al., "A Practical Toolkit For Making Portable Compilers" , Communications of the ACM, Vol. 26, No. 9, September 1983 [hereinafter "Tanenbaum"]. A similar approach is utilized in U.S. Pat. No. 4,667,290, issued to Goss et al., entitled "Compilers Using A Universal Intermediate Language" [hereinafter "Goss"].
Existing common intermediate language techniques, however, suffer from a number of significant problems, and therefore have limited utility in telecommunication service applications. A major problem with the Tanenbaum approach is the loss of original input information when the interface input code is translated to an intermediate language. The original input information is lost because Tanenbaum uses an intermediate language which is basically an assembly language for a simple stack machine. The Goss patent is primarily directed to interfacing high-level programming languages, of a strongly-typed or procedural form, to different data processors. Goss uses a "quad", with four operative fields, as the basic code structure for the intermediate language. See Goss, col.5, line 60 to col.6, line 38. This inflexible structure may not adequately represent certain SCE outputs, such as non-procedural types of programming code. In addition, the intermediate language in Goss is designed for use with top-down parsing of the high-level programming language code. See Goss, col.5, lines 34-36. The Goss approach therefore may not be well-suited for generating intermediate code to represent typical SCE output code. For example, the Goss intermediate code generated from an SCE output code may not preserve enough SCE output code detail to permit efficient intermediate code optimization. The Goss patent thus does not suggest an appropriate intermediate language structure for use in interfacing, for example, SCEs and EEs in a telecommunication services context.
As is apparent from the above, a need exists for an efficient and flexible telecommunication system interface which permits services developed in different SCEs to be utilized in different EEs, without requiring a separate interface between each SCE and each EE, and without the problems of existing intermediate language techniques.